In computing networks, a virtualized environment refers to a collaboration or combination of hardware and software network resources and functionality into a software-based administrative entity. Network virtualization involves platform virtualization, often combined with resource virtualization. Virtual resources are implemented such that the elements or systems that interface with said virtual resources are unaware of the interface requirements for the underlying system components, whether in the form of hardware or software.
Virtualization may, for example, be applied to physical hardware resources by combining multiple physical resources into shared pools. Alternatively, one physical resource can appear as multiple virtual resources. Moreover, virtual resources can have functions or features that are not available in their underlying physical resources. For example, an operating system may be virtualized to behave as if it has the resources of an entire machine under its exclusive control, when in fact a virtualization layer transparently controls the provisioning of said services to the requesting client systems. The virtualization process effectively ensures that the virtual resources are properly shared and supported.
Virtual machines (VMs) may be located within the hardware of a physical resource (i.e., host). Virtualization may be achieved using a virtual machine manager (VMM), also known as a hypervisor. A hypervisor is typically implemented by a layer of code in software or firmware that operates in a privileged environment on the host and interacts with underlying hardware to share its resources dynamically among several operating systems. In some instances, it may be desirable to migrate (i.e., move) a VM from one location (e.g., a first host) to another location (e.g., a second host) in the computing network environment.
A so-called “live” migration is preferably performed without any interruption in the services provided by the migrating VMs. Accordingly, a migration may involve moving one or more VMs among one or more hosts, transparently, without noticeable application downtime. In order to achieve live migration, a source VM is replicated on a target host. The state of the source VM, including the content of RAM memory, registers, states of emulated devices, etc., are transferred to the target host (while the source VM continues running). When the replicated VM is ready, the source VM is suspended and the replica takes over.
Due to technical challenges, a live VM migration is typically limited to a local environment. Within this local environment, the replicated VM is configured to access the same physical storage and the same physical network as the source VM. There are, however, applications that require migration of a VM to remote environments for the purpose of disaster recovery, closer proximity to client systems, or change of hosting vendor, for example.
Remote migration may result in system instability or unavailability of services due to the associated latencies. That is, for example, if the migration distance is too long or the network bandwidth is too limited, latency in provisioning services may be incongruously perceptible. In some instances, network connections may be lost or host systems may fail, either completely interrupting service or severely degrading performance.
Further in long-distance migration scenarios, a VM may be migrated through a series of shorter migration phases. There is risk associated with losing the VM at one of the intermediate migrations due to lower host reliability or loss of connectivity during the shorter migrations. For example, if a VM is to be migrated between two data centers, intermediate data centers that are relatively less reliability may need to be used. Such migration planning without the provisioning of additional reliability factors undesirably increases the risk of failure.